Sepsis Monitoring and Control

ABSTRACT

A computer-implemented sepsis alerting method is disclosed. The method involves automatically extracting with a computer system, from records maintained for a patient under care in a healthcare facility, information from a electronic medical record, and obtaining with the computer system information about real-time status of the patient. The method also involves using the information from the electronic medical record and the information about the real-time status to determine whether the patient is likely to be suffering from dangerous probability of sepsis, using information from the electronic medical record to determine whether treatment for sepsis is already being provided to the patient, and electronically alerting a caregiver over a network if it is determined that a potentially dangerous level of sepsis exists and that treatment for sepsis is not already being provided.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Application Ser.No. 61/258,450, filed on Nov. 5, 2009, entitled “Sepsis Monitoring andControl,” the entire contents of which are hereby incorporated byreference.

TECHNICAL FIELD

This document relates to computer-based systems and techniques formonitoring a human patient for complex physiological syndromes such assepsis and sepsis shock.

BACKGROUND

Septic shock is one of several inflammatory states (along with sepsisand severe sepsis) that result from a person's systemic response tobacterial infection. In severe cases, tissue perfusion may be greatlyreduced, and a patient may develop shaking chills, fever, hypotension,oliguria, and confusion. Ultimately, sepsis can cause acute failure ofmultiple organs (e.g., lungs, kidneys, and liver), potentially causingdeath. Septic conditions are generally treated by aggressive fluidresuscitation, antibiotics, surgical excision of infected or necrotictissues and drainage of pus, supportive care, and sometimes intensivecontrol of blood glucose and administration of corticosteroids andactivated protein C. Generally, patients suffering severe sepsis areprovided for in an Intensive Care Unit (ICU) of a hospital.

When in an ICU, a patient may be provided for by a variety of equipmentsuch as IV drips and drug delivery mechanisms, bed-side monitors, andthe like. In addition, ICU patients are generally continuously monitoredfor a number of physiological factors, including pulse rate, respiratoryrate, and blood pressure. Periodic tests are also performed on such apatient to obtain updated indications of the patient's currentphysiological status.

SUMMARY

This document describes systems and techniques that may be used tomonitor and detect sepsis (which, as used here, can include severesepsis and septic shock), and detect sepsis treatment that may beperformed on a patient so as to notify caregivers of failures to treatthe patient in a timely manner. For example, if the system fails todetect timely, evidence-based interventions within an Electronic MedicalRecord (EMR), it may provide notifications in the form of an earlywarning clinical alert, such as a page or text message, includingmessages that require proof of a response from the notified caregiver.Such an alert may be in addition to an initial alert provided to acaregiver when the system initially notices that the patient isexhibiting symptoms of sepsis. The subsequent alert may be provided to adifferent caregiver than the initial alert, to help ensure thatfollow-up care will be provided.

In certain implementations, such systems and technique may provide oneor more advantages. For example, patient care and safety may be improvedwhen a system can monitor the patient automatically, and can combinedata from multiple sources, including real-time monitoring ofpatient-connected equipment and extraction of data from electronicmedical records. Also, where the monitoring system is connected to acommunication system, a caregiver can be alerted and can address anydangerous situations that may arise. The alerts may be made judiciouslyalso, so that a caregiver will understand that the alerts are importantwhen they are given. Moreover, the presence or absence of treatment forsuch conditions can be identified by separately checking subsequentactions that have been recorded in an EMR after the time of an initialalert, in addition to continued monitoring of a patient by the system(to determine whether the patient's condition is, in fact, improving).In this manner, patients who are suffering from sepsis may obtain quickintervention and treatment, which can be lifesaving in some situations.

In one implementation, a computer-implemented sepsis alerting method isdisclosed. The method comprises automatically extracting with a computersystem, from records maintained for a patient under care in a healthcarefacility, information from a electronic medical record; obtaining withthe computer system information about real-time status of the patient;using the information from the electronic medical record and theinformation about the real-time status to determine whether the patientis likely to be suffering from dangerous probability of sepsis; usinginformation from the electronic medical record to determine whethertreatment for sepsis is already being provided to the patient; andelectronically alerting a caregiver over a network if it is determinedthat a potentially dangerous level of sepsis exists and that treatmentfor sepsis is not already being provided. The method can also includeelectronically automatically monitoring with the computer system thepatient's electronic medical record to determine whether interventionhas occurred to treat the potentially dangerous level of sepsis; andproviding follow-up electronic alerts if a determination is made thatintervention has not occurred.

In some aspects, obtaining real-time status of the patient comprisesquerying, with the computer system, a bed-side monitor for the patientor a controller to which the bed-side monitor reports information aboutthe patient. Also, determining whether the patient is likely to besuffering from sepsis can comprise applying predetermined rules tovalues of patient parameters obtained with the computer system. Thevalues can include values for patient heart rate, respiration rate, andblood pressure; values generated by a blood test on the patient's blood;and values that include keywords in notes in an electronic medicalrecord for the patient. Machine-readable tangible media storinginstructions for performing the above methods may also be provided.

In another implementation, a computer-implemented system to monitor andreport on patient condition is disclosed. The system comprises acomputer system that implements a data extractor to automaticallyextract, from records maintained for a patient under care in ahealthcare facility, information from a electronic medical record andobtain information about real-time status of the patient. The systemalso comprises a patient evaluator programmed to using extracted by thedata extractor to determine whether the patient is likely to besuffering from dangerous probability of sepsis. In addition, the systemcomprises a contact management system arranged to electronically alert acaregiver over a network if the patient evaluator determines that apotentially dangerous level of sepsis exists. In certain aspects, thesystem can also include an alerting system to automatically monitor thepatient's electronic medical record to determine whether interventionhas occurred to treat the potentially dangerous level of sepsis and toinitiate follow-up electronic alerts if a determination is made thatintervention has not occurred.

The details of one or more embodiments are set forth in the accompanyingdrawings and the description below. Other features and advantages willbe apparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a conceptual flow diagram showing the processing of patientrelated information into a clinical decision in aid of the patient.

FIG. 2A is a block diagram showing processing of various patient-relateddata in order to generate an alert for a caregiver.

FIG. 2B is a schematic diagram of a computer system for alertingcaregivers about sepsis problems with patients in a healthcare facility.

FIG. 3 is a flow chart of a process for monitoring a patient for sepsisproblems and alerting caregivers if problems are identified.

FIG. 4 shows an example of a generic computer device and a genericmobile computer device, which may be used with the techniques describedhere.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

This document describes systems and techniques for identifyingproblematic physiological conditions for a patient who may be sufferingfrom sepsis. The systems and techniques take into account real-time datafrom equipment that is currently connected to the patient and otherpatient test data from external sources, which are sources that are notmeasuring a current (or near current) patient status. Such externalsources may store electronic data that has been reported from a hospitallaboratory on tests that have previously been performed on the patient,the patient's blood or tissue, or a similar source. The data that isaccessed by the systems may be analyzed in a predetermined manner andaccording to established rules to determine whether the patient issuffering from sepsis.

When such a positive determination is made, the systems mayautomatically notify an appropriate caregiver. One mechanism fornotification may include identifying a caregiver of an appropriate type(e.g., a physician or a particular specialist physician) and thenidentifying a particular caregiver (e.g., a physician who is currentlyon call). Contact information for the particular caregiver may then beaccessed and an alerting message may be sent to the caregiver. Themessage may include a page or an automated telephone call. The messagemay also include a text message or email message. The message may alsoinclude information about the patient and the patient's status (e.g.,the message may list the patient's current vital signs). Alternatively,or in addition, the message may include a mechanism, such as aselectable hyperlink, to permit the recipient caregiver to accessadditional information about the patient's condition. For example, thehyperlink may lead to an EMR or report from an EMR for the patient, sothat the caregiver can quickly see all information that might berelevant for them to determine the best course of care for the patient.

The initial alert may also be blocked upon the system determining thatappropriate treatment is already being provided to the patient. Forexample, upon identifying that the patient may be suffering from sepsis,the system may check the patient's EMR to identify whether actionsdirected to treating sepsis have been taken by caregivers recently. Forexample, the system may check the EMR to determine whether a caregiverhas notified a sepsis team, whether a caregiver has placed a centralline, or has ordered another treatment that indicates that sepsis orsymptoms of sepsis are already being addressed for the patient.

Because sepsis can be a very serious condition, the system may also makeefforts to determine objectively whether the patient has been properlytreated for the condition that raised an alert of sepsis, after an alertis delivered. For example, the system may continue to monitor thepatient's condition to determine whether it has improved. The system mayalso periodically check the patient's EMR to determine whether acaregiver has entered a note to indicate that they took an appropriatefollow-up action on the patient, such as by increasing fluids orantibiotics to the patient, and the other actions noted in the priorparagraph.

FIG. 1 is a conceptual flow diagram showing the processing of patientrelated information into a clinical decision in aid of the patient. Inthe figure, a patient information system 100 is shown as providinginformation about a patient to a caregiver 108. The patient is connectedto a bed-side monitor 102 and thus may be an ICU patient in relativelyserious condition. The bed-side monitor 102 includes electroniccomponents for measuring parameters of the patient in real-time andturning those parameters into machine- and/or human-discernablevariables. For example, light propagation through a relatively thinportion of a patient's anatomy (e.g., a fingertip) can be measured, anda number can be generated that represents a blood oxygen level for thepatient. Other monitored variables may include blood pressure,respiration rate, heart/pulse rate, and patient temperature.

Other variables may be measured non-continuously or manually and may beentered, e.g., by a caregiver such as a physician or nurse, into an EMRsystem in a familiar manner. Such variables may include patienttemperature and blood pressure in appropriate circumstances. Yet othervariables may be determined from testing of the patient's blood ortissue outside the patient's room, such as by drawing the patient'sblood and providing it to a laboratory for testing. Such variables mayinclude, among many other things, white blood cell count, lactate, base,and anion gap.

Certain of such parameters may be read by an alerting system 104 that isin electrical or other such communication with the bed-side monitor 102.The alerting system 104 may be a computer-implemented system that isprogrammed to gather patient-related information from multiple sources,including the controller for the bed-side monitor 102 (or from the EMRif the EMR itself obtains the information from the monitor), and toapply rules to such gathered data in order to determine whether apotentially dangerous situation exists for the patient, such as acondition that indicates that the patient may be suffering from sepsis.The alerting system 104 in this example also acquires information froman EMR system and applies the rules to that information and the othergathered information.

Such gathering of information by the alerting system may occurperiodically according to a clock that is associated with the alertingsystem 104, or it may occur in response to a patient-related event, suchas a substantial change in bed-side monitor parameters being provided tothe alerting system 104 (either directly or through the EMR system 106).

The information extracted by the alerting system 104 from the EMR system106 can take a variety of forms. For example, laboratory results can beassociated with certain conditions of the patient. Also, text in medicalrecords can be identified, parsed, and interpreted by the system 100,and can be used to match predetermined words so as to identify conceptsthat are being addressed by such text. Billing codes may also beanalyzed to determine what activities have been taken with respect to apatient.

The alerting system 104 is shown as sending communications to acaregiver 108. The communications may take a variety of familiar formssuch as pager messages in text, or standard text messages, among otherpossibilities. Sending of the messages may be based upon an automaticdetermination by the alerting system 104 that the patient may besuffering from sepsis or septic shock, and the alert may be designed todraw a corrective response from the caregiver, such as having thecaregiver come to the patient's aid and administer to the patient, or tohave the caregiver contact another caregiver (e.g., a shift nurse who ison duty) to provide follow-up, including care for the patient.

The caregiver 108 may read any provided messages, which, based on adetermination made by the alerting system 104, will indicate that adangerous sepsis condition may exist. The caregiver 108 may then returnto the patient's room, review the bed-side monitor 102 and itsparameters in more detail, and change the patient's care to ensure thepatient's safety. The caregiver 108 can also call into an ICU and directanother caregiver to modify a course of treatment for the patient. Forexample, the patient may be provided with additional fluids, be givenantibiotics, be scheduled for surgery for the excision of infected ornecrotic tissues and drainage of pus, or be otherwise treated.

Also, modification of the bed-side monitor's 102 operation can beachieved by the caregiver 108 either directly or remotely, and whetherautomatically or manually, and is shown in the figure by an arrowleading back from the alerting system 104 to the bed-side monitor 102.For example, the alerting system 104 may determine that the bed-sidemonitor 102 needs to be reset or otherwise adjusted, at least untilcaregiver 108 can turn their attention to the bed-side monitor 102 andmanually override whatever setpoint has been automatically selected.Such automatic override may be allowed only under circumstances where ithas been determined that such action does not create a risk to thepatient.

The provision of an initial alert may be blocked (or a different, lesserform of alert may b provided) before or after a determination has beenmade that the patient may have sepsis, if the system determines that thepatient is already being treated for sepsis. For example, the system mayanalyze the patient's EMR to determine whether a sepsis team has beennotified recently, whether a caregiver has placed a line for the patientor increased antibiotics for the patient, or taken other actions thatare consistent with the caregiver or caregivers recognizing that thepatient needs to have a sepsis condition addressed.

Another arrow is shown leading from the caregiver 108 back to the EMRsystem 106, to signify that when the caregiver 108 attends to thepatient, the caregiver may make a note in the patient's EMR. Forexample, the physician may record that the patient has been provided acertain level of antibiotics that differs from the level the patient wasreceiving before the generation of the alert to the caregiver 108.

The two-way arrow between the EMR system 106 and the alerting system 104indicates that the alerting system may schedule an automatic follow-upcheck of the patient's EMR data to determine whether appropriatefollow-up by the caregiver has occurred. For example, the alertingsystem 104 may not simply depend on the caregiver's 108 response to analert to assume that the patient's treatment has changed. Instead, thealerting system 104 may check the patient's EMR. Such a check mayinitially involve a check for all notes or other entries in thepatient's EMR after the time of the alert. Those entries may then bemapped to topics, keywords, or billing codes that are known to be properresponses to the condition of the patient that originally generated thealert, which in this case could have been sepsis, severe sepsis, or theonset of septic shock. For example, the alerting system 104 may checkfor the presence of an entry that indicates that the patient was givenadditional fluids or antibiotics.

If the check of the EMR data does not plainly indicate that appropriatesteps have been taken, the alert system 104 may take appropriatefollow-up action, including escalating action. For example, the system104 may alert the caregiver 108 again and request a positive response.If such a response is not adequate, the system may notify an alternativecaregiver or caregivers, such as a shift nurse or a supervisoryphysician, until positive evidence is received that the patient has beenattended to. Depending on the circumstances, an affirmative responsefrom a caregiver, including caregiver 108, may be sufficient to causethe system 104 to wait, but at other points, evidence-basedconfirmation, such as in the form of entries in the EMR system, may berequired (at least to avoid elevating the situation to anothercaregiver).

FIG. 2A is a block diagram showing processing of various patient-relateddata in order to generate an alert for a caregiver. Such processingoccurs by use of an alerting system 200. The system 200 may include adata extractor 202 and contact management system 206 that are added toan existing EMR system so as to provide alerting functionality. Theexisting system, before the addition of the alerting system 200, mayinclude a variety of institutional databases 208 that may take a varietyof forms, and may be used by a healthcare institution in its ordinarycourse of business. Such databases could range from EMR databases ofvarious types, databases that track contact information for caregiverswho are employed by a system, accounting databases, and databases usedto assist caregivers with making diagnoses (e.g., expert systems). Thesystem 200 may also include a data warehouse 204, which may be providedwith read access to various portions of the institutional databases 208and may be employed to extract information from the institutionaldatabases 208 and reformat and store the data where it can be queriedand otherwise manipulated more readily by components such as the dataextractor 202.

While described here as an addition to an existing healthcare computingsystem, the alerting system 200 may also be implemented at the same timeas the main system. However, various advantages may be obtained byimplementing the alerting system 200 as a distinct module from othersub-systems that are part of the main system, including by installingthe alerting system 200 on a separate server system, with hooks to thealerting system 200 in modules for other portions of a healthcareinformation system.

The data extractor 202 may be triggered by an internal clock on aperiodic basis to extract data from the data warehouse 204, where therelevant data—in this example—relates to conditions of patients in ahealthcare system who are currently connected to bed-side monitors.Several particular pieces of data are gathered in one example relatingto sepsis monitoring. First, information from laboratory reports on thepatient's white blood cell count, lactate, base, and anion gap may beretrieved and identified. Such information may be indicative of ahypotension or organ hypo perfusion. Second, the EMR system may bequeried for any culture order in a determined previous time period, suchas a prior 96-hour time period. Such orders may represent a suspicion,by a caregiver, that the patient is suffering from infection. Third, theEMR system and/or the bed-side monitor may be queried for informationabout patient temperature, heart rate, and respiration rate, and alsopatient white blood cell count (e.g., via block 210). Such informationmay indicate a problematic systematic inflammatory response by thepatient, in response to infection. The alert system may then combine thevarious access information according to a formula to generate a “score”for the patient, where an alert is generated if a predetermined score isexceeded. Additional information may be taken into account indetermining the score or in determining whether the score should triggeran alert, including the weight, age, and general physical condition ofthe patient, and other problems that the patient may have (e.g., heartdisease or other conditions that could lower the patient's ability tofight infection).

Notes in the EMR may also be parsed and analyzed. For example, thesystem may identify terms in the notes such as “sepsis,” “inflammation,”“infection,” and the like, as clues to the caregivers' beliefs thatthere may be a sepsis-related problem for the patient.

Rules may also be applied across multiple readings to ensure thattransient conditions of the patient do not generate a false positive ora false negative. For example, the alert system may ensure that heartrate, respiratory rate, and blood pressure exceed threshold valuesacross four consecutive readings. Moreover, rules may be used tosuppress alerts in appropriate circumstances. For example, alerts may besuppressed for a predetermined period, such as 14 days, after evidenceshows that the patient has been attended to for sepsis, under theassumption that the care giving team will know about the problem,continue to be treating it, and may lose faith in the system if thesystem provides unnecessary alerts.

The querying of the EMR system in these examples may be in real-time orin batch mode. For example, a query to the EMR system may be performedfor each patient by an alerting system. Alternatively, all relevantpatient data may be pulled periodically from the EMR system to aseparate data storage system (e.g., the data warehouse 204) local to thealerting system, and the alerting system may then access the datadirectly from there, so as to better balance the loads that may beplaced on the EMR system.

If the data extractor 202 makes a determination that a potentiallydangerous condition exists, it may check the patient's EMR in thevarious manners discussed above to determine whether the patient isalready being treated for sepsis. If the patient is being treated, thesystem may continue to monitor the patient, but need not send out analert. If the patient is being treated in an ambiguous manner—so that itis possible that the caregiving team recognizes the sepsis condition andit is possible that they do not—a lesser level of alert may be sent,such as by a note being placed automatically in the patient's EMR or anon-urgent message being sent to an appropriate caregiver (e.g., a shiftnurse).

If an alert is appropriate, the system may send a signal to the contactmanagement system 206, which may be a system that prepares and routes avariety of messages to mobile devices 216 of caregivers in the system200. Such preparation and routing, in this example, may include aninitial determination by the system 200, of which caregiver is currentlyresponsible for the patient, such as an on-call physician or nurseassigned to an ICU where the patient is stationed. The preparation ofthe message may further include the generation of a message whose textindicates an identity of the patient, either directly (by name) orindirectly (by location in the ICU) and the nature of the condition thattriggered the notification. The contact management system may furtherquery the institutional databases 208 such as to find contactinformation (e.g., an email address) for caregivers.

In certain circumstances, the generation of an alerting message may beblocked or delayed. Typically, such action may occur to prevent thegeneration of false positive reports that would result in caregivershaving less respect for the system 200, and in the quality of care forpatients declining. For example, the system 200 may require that analerting condition be present for a certain number of cycles of thesystem 200, such as over a period of several hours or measurementcycles. Also, the system 200 may limit the number of notifications thata particular caregiver receives, so that the caregiver is not beingbombarded with notifications about a particular patient, and is renderedunable to determine which are serious and which are not.

The alert message that is provided to a caregiver may be “rich”, in thatit may permit interaction by the alerted caregiver in order to obtainadditional information about the patient and the patient's conditionautomatically. For example, the message may include one or morehyperlinks that aim back to the patient's EMR (which can be exposedafter the caregiver provides adequate ID and password) so that thecaregiver can obtain full access to the patient's EMR and thus can makea remote determination about how best to handle the event. For example,a physician at home may determine that the best immediate route is tohave an on-site caregiver enter the patient's room and directly monitorthe patient. The physician may then talk to the on-site caregiver,including by video link or transmitted photos (e.g., from physiciansmartphone to nurse smartphone or tablet PC) to obtain additionalinformation that may not have been otherwise accessible to thephysician.

The system 200 may, after providing the alert, wait a predetermined timeperiod, whose duration can depend on the severity of the sepsiscondition as determined by the various gathered information identifiedabove, before checking the patient's data again. Such a check may be ofupdated patient status information to determine whether the patient'sstatus has improved since the alert was generated (e.g., better bloodpressure, heart rate, and respiratory rate). The check may also be forentries in the patient's EMR after the time of the alert so as todetermine whether responsive care has been given to the patient. If thesystem 200 determines that there is a problem in either situation, itmay send another alert, either to the initially-alerted caregiver or toanother caregiver. Such an alerting process may continue until thesystem 200 has seen evidence that the patient's problem has beenadequately addressed.

In this manner, the system 200 can automatically identify potentialdangerous conditions for a patient even if no caregiver has yet to makea determination that the patient has a sepsis problem. The system 200can also generate an alert that is custom, in that it can be transmittedremotely to a caregiver using whatever messaging technology thecaregiver prefers (e.g., smart phone, text pager, etc.) and can giveinformation about the nature of the alert. In addition, it can managethe number and type of message that is delivered so that the overalloperation of system 200 is not overly intrusive to caregivers. Moreover,the system 200 may ensure, separately from explicit reporting bycaregivers, that the patient's needs have been addressed. As a result,the care of a patient may be improved.

FIG. 2B is a schematic diagram of a computer system 220 for alertingcaregivers about sepsis problems or similar problems with patients in ahealthcare facility. In general, the system 220 may comprise all or aportion of system 200 in certain implementations—though more detail isshown for certain portions of system 220

The system 220 generally includes an alerting computer system 222 whichmay be made up of one or more computer servers programmed with computercode to analyze various scattered data in a healthcare system so as togenerate an alert that a dangerous condition may exist for one or morepatients who are using bed-side monitors in the system 220. The computersystem 222 may capture its data from a number of bed-side monitors 230via a data aggregation unit 228. The unit 228 may include a databasethat stores and manages various parameters concerning bed-side monitorsthat are operating in one or more ICU's in a healthcare system,including bed-side monitor set points and readings (e.g., respirationrate, heart rate, oxygen content, etc.) taken by the various bed-sidemonitors. The unit 228 may also include an interface that operatesaccording to a known API so that data about the bed-side monitors 230can be communicated to the computer system 222 in a predefined manner.

The computer system 222 may also gather data from a data warehouse 224,which may take a variety of forms, and is generally designed to be acentralized location where data about a healthcare system may be easilyaccessed and manipulated. The warehouse 224 may in turn query a datasystem 226 for the entire healthcare system. The data system 226 isshown here as a rack of servers to indicate that the data system 226will typically involve a number of different servers scattered across acampus or larger network of healthcare facilities, though the particularphysical form of any of the computer systems or sub-systems shown hereis not critical and can take any appropriate form. Also, where the termserver is used, the system may implement the relevant functionality in aportion of a server (e.g., a virtual machine), a single dedicatedservers, or multiple servers.

The system 222 includes a variety of components that allow it to obtaindata relating to bed-side monitoring of patients and to generate alertsin appropriate circumstances. Although the receipt of information fromthe bed-side monitors 230 is shown here as being direct, suchinformation could also be obtained through an EMR system.

An interface 232 is provided so that system 222 can query unit 228, datawarehouse 224, and other appropriate data stores to obtain informationthat can be used to determine the condition of a patient or patients.Such data may be used by a patient evaluator 234, in combination withpatient evaluation rules 238 that are stored by the system 222, todetermine whether a patient could be in a potentially dangerouscondition. Patient data 240 may also be stored and used by the patientevaluator 234, such as identification information for the patient, theICU in which they are staying, etc. Example rules are discussed aboveand below in more detail.

An alert module 236 may be notified by the patient evaluator 234 when apotentially dangerous condition is determined to exist. The alert modulemay then gather information about the patient, and the alertingcondition, may make a determination about whether a likely problemexists, and may prepare a message (box 246) to be sent to an appropriatecaregiver.

The system 222 may also generate information in addition to individualalerts. For example, patient reports may be generated for administratorswho query the system 222, and such reports may indicate the number oftimes an alert has been generated for a particular patient and thenature of the alerts. Such a query may be made by an administratortrying to determine whether alerts have been acted on appropriately, orby a caregiver from the patient's room, to determine how long analerting condition has existing, in determining a proper remedial planof care for the patient. Also, more general ICU reports may begenerated, and may show an administrator a compilation of alert activityfor one or more ICU's, which may assist the administrator in staffingcaregivers or determining whether appropriate ICU care is beingprovided. The reports may be persistent, in that they are generatedautomatically, such as being generated each day for an arriving shiftnurse. The reports may also be triggered manually, such as by asupervising physician who wants to see an overview of alerting activityfor a patient, a ward, or an entire system.

FIG. 3 is a flow chart of a process for monitoring a patient for sepsisproblems and alerting caregivers if problems are identified. The processbegins at box 302 where an inquiry for patient status is trigger. Thetriggering may occur on a periodic basis for all patients who arecurrently active in the system, or only patients flagged as having acertain status, such as ICU patients. The timing of the inquiries may bevaried so that different patients are addressed at different times, anda load manager may be employed to smooth out the load on the system ofmaking the inquiries.

At box 304, data sources are queried for patient status information.Such querying may occur as described above, and may including queryingof an EMR record for the patient to obtain various measured and testdata for the patient. The query may also obtain real time status datafor the patient, such as heart rate, respiratory rate, and bloodpressure, either by querying an EMR system that collects suchinformation or by querying bed-side monitors of a patient directly.

At box 306, a sepsis determination is made. The determination may bemade according to an algorithm that takes into effect the variousmeasured variables and provides appropriate weights to each. Theparticular weights and variables may be determined readily byappropriate study of a patient population, and actual diagnoses byphysicians of patients in the population. Particular factors may bebroken into 4 domains as follows:

“Domain 1” (measured within a prior 72 hour window). This domainincludes inspection to identify any microbiology culture order, whichmay indicate a suspicion by a caregiver that the patient has aninfection.

“Domain 2” (measured within a prior 24 hour window). This domain wouldbe triggered by two or more of the following: respiratory rate>25breaths/min; heart rate>90 beats/min; white Blood Cells>12000 cells/mm³;white Blood Cells<4000 cells/mm³; body temperature>38.6 C; Bodytemperature<36.0 C. Such factor may indicate systematic inflammatoryresponse.

“Domain 3” (measured within a prior 24 hour window). This domain wouldbe triggered by any one of the following: mean arterial BloodPressure<65 mm Hg or systolic blood pressure<90, lactate>2.5 mmol/l;base<−5 mmol/l; anion gap>12 mEq/L. Such factors may indicatehypotension or organ hypo perfusion.

“Domain 4” is additional rules that a design of a system may want toimpose, based on experience with an ICU program and/or an automaticalerting system. For example, rules may impose that heart rate, meanarterial blood pressure, and respiratory rate should exceed thresholdlevel for 3 consecutive readings before an alert is generated. Also, arule may be imposed so that the same patient case is not alerted in 14days. The syntaxes for certain rules may be pre-programmed into a systemalso, and a user may be allowed to select which rules to apply andtriggering values for those rules. For example, a user could change thenumbers 3 and 14 in the prior two rules, so as to fine-tune the rules tothe needs of a particular organization.

Under a “failure of rescue” concept, rules may identify a detection of aprovider action or inaction that is to be triggered only if the providerhas not followed up with early goal directed therapy. For example,detection of central venosus pressure (CVP) can be a sign to the systemthat providers were aware of such a patient condition. Missing this datapoint is a “failure to rescue” event that triggers an alert.

At box 308, the process determines whether an alert is appropriate. Forexample, according to the rule just mentioned, the system may determinethat the patient is in severe sepsis, but EMR data may indicate that thecare giving team is already well-aware of that fact and is dealing withit. As described above, such a determination can be made by recognizingin the EMR data that a sepsis team has been alerted, that the patienthas recently been given a central line, or via other actions by thecaregiving team that are consistent with a sepsis treatment course ofaction. In such a situation, an alert would be unnecessary andpotentially annoying.

At box 310, appropriate caregivers are identified, and an alert oralerts are generated and sent. The appropriate caregiver may bedetermined by querying a hospital information system to identify thelocation of the patient and the caregiver currently responsible for thatlocation. Also, contact records in the system may be queried so as toobtain a page number, email address, or other appropriate contactinformation for the caregiver.

At box 312, the process monitors for a response form the caregiver. Forexample, the caregiver may be asked to confirm that they received thealert, and if such confirmation is not received within a predeterminedtime period (e.g., several minutes), a separate message may be sent toanother, back-up caregiver.

At box 314, follow-up alerts are provided if necessary. As discussedabove, the EMR data may be monitored for positive evidence that thealerting condition is being address by the care giving team. If suchevidence does not appear within a predetermined time period, the processmay return back to generating more alerts, either to the caregivers whowere initially alerted or to others in an organizations.

A study of particular patients in ICUs was conducted in particularsettings, as next described, in order to determine whether intelligentevaluations of patient condition could be made automatically accordingto particular predetermined rules.

Example

An “sepsis sniffer” automatic screening tool like the systems describedabove was applied to a three-month data set of patients' data fromelectronic medical records in a medical intensive care unit. In thestudy, 50 of 401 consecutive patients developed severe sepsis/septicshock during an ICU stay. The sniffer demonstrated a sensitivity of 86%,specificity 83%, and positive predictive value 43%.

In the studied system, a Microsoft SQL-based integrative database,“Intensive Care Unit (ICU) data mart”, accumulated data within one hourfrom its entry into the electronic medical records and served as themain data source for rules development. Severe sepsis and septic shockwere defined according to standard consensus conference criteria. Thesecriteria included blood culture order within 72 hours AND (two of(respiratory rate above 25 OR WBC above 12000 OR temperature below 36.0C) and (heart rate above 90 OR WBC below 4000 OR temperature above 38.6C)) AND hypotension or organ hypo perfusion as indicated by (meanarterial blood pressure below 65 OR lactate above 2.5) or (metabolicacidosis base less than −5 OR anion gap greater than 12).

The data set was retrospectively continuously scanned with an electronicalert based on severe sepsis/septic shock criteria (“sniffer”).

Results. From 401 consecutive admissions to the medical ICU during 90days study period (August-October 2007). Two critical care expertsblinded to the sniffer results diagnosed 50 severe sepsis/septic shockcases. The screening engine sent a total of 101 alerts and correctlyidentified 43 patients with the syndrome.

EMR screening algorithm based on the consensus conference for severesepsis/septic shock criteria had a sensitivity of 86% (95% CI 73-94) anda specificity of 83% (95% CI 78-87). Positive and negative likelihoodratios for diagnosis of severe sepsis/septic shock were 5.01 (95% CI3.87-6.50) and 0.17 (95% CI 0.08-0.34). Electronic alert had a positivepredictive value of 43% (95% CI 33-52) and negative predictive value 98%(95% CI 95-99).

Conclusions. In this study we demonstrated the feasibility of near-realtime computerized screening of EMRs for early diagnosis of severesepsis/septic shock syndrome (sepsis “sniffer”). The sniffer based onstandard consensus conference criteria demonstrated adequate positivepredictive.

FIG. 4 shows an example of a generic computer device 400 and a genericmobile computer device 450, which may be used with the techniquesdescribed here. In particular, computer device 400 may be used in thevarious servers identified above, and mobile computer device 450 may beused by caregivers in receiving and responding to alerts. Computingdevice 400 is intended to represent various forms of digital computers,such as laptops, desktops, workstations, personal digital assistants,servers, blade servers, mainframes, and other appropriate computers.Computing device 450 is intended to represent various forms of mobiledevices, such as personal digital assistants, cellular telephones,smartphones, and other similar computing devices. The components shownhere, their connections and relationships, and their functions, aremeant to be exemplary only, and are not meant to limit implementationsof the inventions described and/or claimed in this document.

Computing device 400 includes a processor 402, memory 404, a storagedevice 406, a high-speed interface 408 connecting to memory 404 andhigh-speed expansion ports 410, and a low speed interface 412 connectingto low speed bus 414 and storage device 406. Each of the components 402,404, 406, 408, 410, and 412, are interconnected using various busses,and may be mounted on a common motherboard or in other manners asappropriate. The processor 402 can process instructions for executionwithin the computing device 400, including instructions stored in thememory 404 or on the storage device 406 to display graphical informationfor a GUI on an external input/output device, such as display 416coupled to high speed interface 408. In other implementations, multipleprocessors and/or multiple buses may be used, as appropriate, along withmultiple memories and types of memory. Also, multiple computing devices400 may be connected, with each device providing portions of thenecessary operations (e.g., as a server bank, a group of blade servers,or a multi-processor system).

The memory 404 stores information within the computing device 400. Inone implementation, the memory 404 is a volatile memory unit or units.In another implementation, the memory 404 is a non-volatile memory unitor units. The memory 404 may also be another form of computer-readablemedium, such as a magnetic or optical disk.

The storage device 406 is capable of providing mass storage for thecomputing device 400. In one implementation, the storage device 406 maybe or contain a computer-readable medium, such as a floppy disk device,a hard disk device, an optical disk device, or a tape device, a flashmemory or other similar solid state memory device, or an array ofdevices, including devices in a storage area network or otherconfigurations. A computer program product can be tangibly embodied inan information carrier. The computer program product may also containinstructions that, when executed, perform one or more methods, such asthose described above. The information carrier is a computer- ormachine-readable medium, such as the memory 404, the storage device 406,memory on processor 402, or a propagated signal.

The high speed controller 408 manages bandwidth-intensive operations forthe computing device 400, while the low speed controller 412 manageslower bandwidth-intensive operations. Such allocation of functions isexemplary only. In one implementation, the high-speed controller 408 iscoupled to memory 404, display 416 (e.g., through a graphics processoror accelerator), and to high-speed expansion ports 410, which may acceptvarious expansion cards (not shown). In the implementation, low-speedcontroller 412 is coupled to storage device 406 and low-speed expansionport 414. The low-speed expansion port, which may include variouscommunication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet)may be coupled to one or more input/output devices, such as a keyboard,a pointing device, a scanner, or a networking device such as a switch orrouter, e.g., through a network adapter.

The computing device 400 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as astandard server 420, or multiple times in a group of such servers. Itmay also be implemented as part of a rack server system 424. Inaddition, it may be implemented in a personal computer such as a laptopcomputer 422. Alternatively, components from computing device 400 may becombined with other components in a mobile device (not shown), such asdevice 450. Each of such devices may contain one or more of computingdevice 400, 450, and an entire system may be made up of multiplecomputing devices 400, 450 communicating with each other.

Computing device 450 includes a processor 452, memory 464, aninput/output device such as a display 454, a communication interface466, and a transceiver 468, among other components. The device 450 mayalso be provided with a storage device, such as a microdrive or otherdevice, to provide additional storage. Each of the components 450, 452,464, 454, 466, and 468, are interconnected using various buses, andseveral of the components may be mounted on a common motherboard or inother manners as appropriate.

The processor 452 can execute instructions within the computing device450, including instructions stored in the memory 464. The processor maybe implemented as a chipset of chips that include separate and multipleanalog and digital processors. The processor may provide, for example,for coordination of the other components of the device 450, such ascontrol of user interfaces, applications run by device 450, and wirelesscommunication by device 450.

Processor 452 may communicate with a user through control interface 458and display interface 456 coupled to a display 454. The display 454 maybe, for example, a TFT LCD (Thin-Film-Transistor Liquid Crystal Display)or an OLED (Organic Light Emitting Diode) display, or other appropriatedisplay technology. The display interface 456 may comprise appropriatecircuitry for driving the display 454 to present graphical and otherinformation to a user. The control interface 458 may receive commandsfrom a user and convert them for submission to the processor 452. Inaddition, an external interface 462 may be provide in communication withprocessor 452, so as to enable near area communication of device 450with other devices. External interface 462 may provide, for example, forwired communication in some implementations, or for wirelesscommunication in other implementations, and multiple interfaces may alsobe used.

The memory 464 stores information within the computing device 450. Thememory 464 can be implemented as one or more of a computer-readablemedium or media, a volatile memory unit or units, or a non-volatilememory unit or units. Expansion memory 474 may also be provided andconnected to device 450 through expansion interface 472, which mayinclude, for example, a SIMM (Single In Line Memory Module) cardinterface. Such expansion memory 474 may provide extra storage space fordevice 450, or may also store applications or other information fordevice 450. Specifically, expansion memory 474 may include instructionsto carry out or supplement the processes described above, and mayinclude secure information also. Thus, for example, expansion memory 474may be provide as a security module for device 450, and may beprogrammed with instructions that permit secure use of device 450. Inaddition, secure applications may be provided via the SIMM cards, alongwith additional information, such as placing identifying information onthe SIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory,as discussed below. In one implementation, a computer program product istangibly embodied in an information carrier. The computer programproduct contains instructions that, when executed, perform one or moremethods, such as those described above. The information carrier is acomputer- or machine-readable medium, such as the memory 464, expansionmemory 474, memory on processor 452, or a propagated signal that may bereceived, for example, over transceiver 468 or external interface 462.

Device 450 may communicate wirelessly through communication interface466, which may include digital signal processing circuitry wherenecessary. Communication interface 466 may provide for communicationsunder various modes or protocols, such as GSM voice calls, SMS, EMS, orMMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others.Such communication may occur, for example, through radio-frequencytransceiver 468. In addition, short-range communication may occur, suchas using a Bluetooth, WiFi, or other such transceiver (not shown). Inaddition, GPS (Global Positioning System) receiver module 470 mayprovide additional navigation- and location-related wireless data todevice 450, which may be used as appropriate by applications running ondevice 450.

Device 450 may also communicate audibly using audio codec 460, which mayreceive spoken information from a user and convert it to usable digitalinformation. Audio codec 460 may likewise generate audible sound for auser, such as through a speaker, e.g., in a handset of device 450. Suchsound may include sound from voice telephone calls, may include recordedsound (e.g., voice messages, music files, etc.) and may also includesound generated by applications operating on device 450.

The computing device 450 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as acellular telephone 480. It may also be implemented as part of asmartphone 482, personal digital assistant, or other similar mobiledevice.

Various implementations of the systems and techniques described here canbe realized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

These computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms “machine-readable medium”“computer-readable medium” refers to any computer program product,apparatus and/or device (e.g., magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniquesdescribed here can be implemented on a computer having a display device(e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor)for displaying information to the user and a keyboard and a pointingdevice (e.g., a mouse or a trackball) by which the user can provideinput to the computer. Other kinds of devices can be used to provide forinteraction with a user as well; for example, feedback provided to theuser can be any form of sensory feedback (e.g., visual feedback,auditory feedback, or tactile feedback); and input from the user can bereceived in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in acomputing system that includes a back end component (e.g., as a dataserver), or that includes a middleware component (e.g., an applicationserver), or that includes a front end component (e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the systems and techniquesdescribed here), or any combination of such back end, middleware, orfront end components. The components of the system can be interconnectedby any form or medium of digital data communication (e.g., acommunication network). Examples of communication networks include alocal area network (“LAN”), a wide area network (“WAN”), and theInternet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

A number of embodiments have been described. Nevertheless, it will beunderstood that various modifications may be made without departing fromthe spirit and scope of the invention. For example, much of thisdocument has been described with respect to ICU monitoring withattending physicians, but other forms of patient monitoring andreporting may also be addressed.

In addition, the logic flows depicted in the figures do not require theparticular order shown, or sequential order, to achieve desirableresults. In addition, other steps may be provided, or steps may beeliminated, from the described flows, and other components may be addedto, or removed from, the described systems. Accordingly, otherembodiments are within the scope of the following claims.

1. A computer-implemented sepsis alerting method, comprising:automatically extracting with a computer system, from records maintainedfor a patient under care in a healthcare facility, information from aelectronic medical record; obtaining with the computer systeminformation about real-time status of the patient; using the informationfrom the electronic medical record and the information about thereal-time status to determine whether the patient is likely to besuffering from dangerous probability of sepsis; using information fromthe electronic medical record to determine whether treatment for sepsisis already being provided to the patient; and electronically alerting acaregiver over a network if it is determined that a potentiallydangerous level of sepsis exists and that treatment for sepsis is notalready being provided.
 2. The method of claim 1, further comprising:electronically automatically monitoring with the computer system thepatient's electronic medical record to determine whether interventionhas occurred to treat the potentially dangerous level of sepsis; andproviding follow-up electronic alerts if a determination is made thatintervention has not occurred.
 3. The method of claim 1, whereinobtaining real-time status of the patient comprises querying, with thecomputer system, a bed-side monitor for the patient or a controller towhich the bed-side monitor reports information about the patient.
 4. Themethod of claim 1, wherein determining whether the patient is likely tobe suffering from sepsis comprises applying predetermined rules tovalues of patient parameters obtained with the computer system.
 5. Themethod of claim 4, wherein the values include values for patient heartrate, respiration rate, and blood pressure.
 6. The method of claim 4,wherein the values include values generated by a blood test on thepatient's blood.
 7. The method of claim 4, wherein the values includekeywords in notes in an electronic medical record for the patient.
 8. Amachine-readable tangible medium having recorded and stored thereoninstructions that when executed on one or more electronic computers,perform actions comprising: automatically extracting with a computersystem, from records maintained for a patient under care in a healthcarefacility, information from a electronic medical record; obtaining withthe computer system information about real-time status of the patient;using the information from the electronic medical record and theinformation about the real-time status to determine whether the patientis likely to be suffering from dangerous probability of sepsis; usinginformation from the electronic medical record to determine whethertreatment for sepsis is already being provided to the patient; andelectronically alerting a caregiver over a network if it is determinedthat a potentially dangerous level of sepsis exists;
 9. Themachine-readable tangible medium of claim 8, wherein the actions furthercomprise: electronically automatically monitoring with the computersystem the patient's electronic medical record to determine whetherintervention has occurred to treat the potentially dangerous level ofsepsis; and providing follow-up electronic alerts if a determination ismade that intervention has not occurred.
 10. The machine-readabletangible medium of claim 7, wherein obtaining real-time status of thepatient comprises querying, with the computer system, a bed-side monitorfor the patient or a controller to which the bed-side monitor reportsinformation about the patient.
 11. The machine-readable tangible mediumof claim 7, wherein determining whether the patient is likely to besuffering from sepsis comprises applying predetermined rules to valuesof patient parameters obtained with the computer system.
 12. Themachine-readable tangible medium of claim 11, wherein the values includevalues for patient heart rate, respiration rate, and blood pressure. 13.The machine-readable tangible medium of claim 11, wherein the valuesinclude values generated by a blood test on the patient's blood.
 14. Themachine-readable tangible medium of claim 11, wherein the values includekeywords in notes in an electronic medical record for the patient.
 15. Acomputer-implemented system to monitor and report on patient condition,the system comprising: a computer system that implements a dataextractor to automatically extract, from records maintained for apatient under care in a healthcare facility, information from aelectronic medical record and obtain information about real-time statusof the patient; a patient evaluator programmed to using extracted by thedata extractor to determine whether the patient is likely to besuffering from dangerous probability of sepsis; and a contact managementsystem arranged to electronically alert a caregiver over a network ifthe patient evaluator determines that a potentially dangerous level ofsepsis exists.
 16. The system of claim 15, further comprising analerting system to determine whether the patient is already receivingtreatment for sepsis and to prevent the contact management system fromgenerating an electronic alert of the patient is already receivingtreatment for sepsis.
 17. The system of claim 15, further comprising analerting system to automatically monitor the patient's electronicmedical record to determine whether intervention has occurred to treatthe potentially dangerous level of sepsis and to initiate follow-upelectronic alerts if a determination is made that intervention has notoccurred.